SPECIFICATION 

Electronic Version 1.2.8 
Stylesheet Version 1 .0 

Method And System For Delayed 
Cookie Transmission In A Client- 
Server Architecture 

Background of Invention 

1 . Field of the Invention Th^ invention pertains to the field of client-server 
electronic communication, and more particularly to use of a cookie or token to 
provide and maintain state information. 

2. Description of the Related ArtThe typical client-server architecture using a 
client browser and server generated or provided web pages is generally considered a 
stateless environment. To provide and maintain state information, it is known to use 
tokens or "cookies". 

A client user logging into a site may receive many different cookies, each with its 
respective purpose. In some applications, the user receives a cookie that is used to 
select a particular webserver for load balancing; a cookie representing the user's 
application session, one or more cookie(s) representing the user's session used for 
Single Sign On with other systems, and multiple GET ACCESS cookie(s) used for Single 
Sign On with other GET ACCESS Systems. 

The generation of some cookies, namely the GET ACCESS cookies, can take an 
extended period of time. In the case of the GET ACCESS cookies, the application 
server, on behalf of the user performs a simulated login. During the login process the 
application server connects to the remote system over https, screen scraps the html, 
logs in as the user, and retrieves the cookies from the resulting http headers. If this 
login fails a change password is performed on behalf of the user and the login 
reattempted. All of this could take quite some time degrading login performance even 
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though the user does not need these cookies immediately upon entering the 
application. 



[0005] What is needed is a system and method to allow a user into a site with only the 
cookies that are immediately necessary. Other cookies, such as the GET ACCESS 
cookies, are delivered asynchronously as they become available. 

[0006] The preceding description is not to be construed as an admission that any of the 
description is prior art to the present invention. 

Summary of Invention 

[0007] In one aspect, the invention provides a method and system for sending 

information to a client browser comprising sending a first request from a client to a 
server. Responsive to the first request, initiating a request to create a token. 
J* Responsive to the first request, sending information from the server to the client, the 

P information including at least display data and a first link corresponding to the token. 

m 

]g Rendering the display data in a browser of the client. Sending a request from the 

H" client to the first link. Determining whether the token is created, and if the token is 

He 

m created, sending the token to the client. 
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[0008] In one aspect, the invention further comprises starting a timer after initiating the 



y*. request to create a token. 



\J t [0009] In one aspect, the invention further comprises if the token is not created, 
comparing the timer to a predetermined value. 

[001 0] In one aspect, the invention further comprises if the timer exceeds the 
predetermined value, sending a second link to the client, the second link 
corresponding to the token. 



[0011] 



The specific aspects and advantages of the invention described and illustrated 
herein are illustrative of those which can be achieved by the present invention and are 
not intended to be exhaustive or limiting of the possible advantages that can be 
realized. Thus, the aspects and advantages of this invention will be apparent from the 
description herein or can be learned from practicing the invention, both as embodied 
herein or as modified in view of any variations which may be apparent to those skilled 
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in the art. Accordingly, the present invention resides in the novel parts, constructions, 
arrangements, combinations and improvements herein shown and described. 

Brief Description of Drawings 

[001 2] The foregoing features and other aspects of the invention are explained in the 
following description taken in conjunction with the accompanying figures wherein: 

[001 3] FIG. 1 illustrates a system according to one embodiment of the invention; and 

[0014] FIG. 2 illustrates steps in a method according to one embodiment of the invention. 

[001 5] It is understood that the drawings are for illustration only and are not limiting. 

Detailed Description of the Drawings 

[001 6] In one embodiment, a request is made from the client to retrieve an http(s) page 
Q- from the server (e.g. login form submitted and client expects resulting html). The 

Ass*- 

• server then spawns a long running process to retrieve the slow cookies and returns 
the fast cookies along with the html to the user immediately. The html returned from 
the server to the client contains a link to a clear gif retrieved over http(s). The clear gif 
is an image file that contains only transparent data, so appears to be "clear." The clear 
gif is not a file but rather the output of a program that listens for notifications that the 
slow cookies have been retrieved. If no such notifications arrive after some period of 
time (e.g., 20 seconds) the program does not return a clear gif but rather redirects the 
client to another URL resulting in the same program being run. This is so that the 
"persistent connection" between the client and the server is not recognized as such 
and dropped by intermediate proxies that do not allow such connections. Eventually 
the slow cookies will be retrieved, the clear gif program notified, and the cookies 
returned in the http headers of the clear gif along with the clear gif itself. After some 
configurable timeout the clear gif could be returned even if the slow cookies never 
arrive to prevent the wasting of resources. 

[001 7] 

Referring now to FIG. 1 , system 1 00 according to one embodiment of the 
invention includes a client 1 02, a server 1 04 and a cookie or token generator 1 06. 
Client 1 02 and server 1 04 are electrically connected to each other by network 1 08. 
Server 104 and cookie generator 106 are electrically connected to each other by either 
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network 1 08, or by network 1 1 0. Network 1 08 can be any of a number of types of 
wired and wireless networks, such as a local area network (LAN) or wide area network 
(WAN). In one embodiment, network 1 08 is the Internet. Network 11 0 can also be any 
of a number of types of wired and wireless networks, and may also be the Internet. 
Depending on the needs of the system, network 108 and 1 10 may be parts of the 
same network, or they may be isolated from each other. 

[001 8] Although not specifically illustrated in FIG. 1 , client 1 02, server 1 04 and cookie 
generator 106 each include removable and fixed software code storage media, a 
processor to run the software code, a memory, input and output devices and network 
interface devices, all interconnected by a system bus. 

[0019] Although in FIG. 1 server 1 04 and cookie generator 106 are illustrated as separate 
entities, it is also possible that they are both elements of the same piece of hardware, 
but can perform different functions. 



[0020] Referring now to FIG. 2, system 1 00 begins at step 202 when client 1 02 sends a 
resource request to server 1 04. This is typically an http or https type of resource 



jM* request that includes a URL corresponding to the requested resource. 



[0021] At step 204, server 1 04 receives the resource request. Although not illustrated in 
ffl FIG. 2, at step 204, server 1 04 also determines whether all the cookies or tokens that 

should be returned to client 1 02 exist or are immediately available. If all of the 
^ cookies or tokens exist, then the requested resource is returned to the client along 

m 

with the cookies or tokens. These cookies or tokens that are immediately available are 
the "fast" cookies. 

[0022] Assuming that there are some cookies or tokens that are not immediately 

available (i.e., they are "slow" cookies), then at step 206, server 104 sends a request 
to cookie generator 1 06 to generate a cookie (e.g., the "slow" cookies). 

[0023] Without waiting for cookie generator 1 06 to generate and return the requested 
cookie, at step 208 server 104 begins to generate or retrieve the html for the 
requested resource. In addition to fast cookies, which are immediately available, the 
html includes a link to the clear gif, as a substitute or place-holder for the slow cookie 
(s). 
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Once server 1 04 has generated or retrieved the html , then at step 210, server 
sends the html, including the link to the clear gif, to client 1 02. 



[0025] At step 212, client 1 02 receives the html, including the "fast" cookies and the link 
to the clear gif. 

[0026] At step 214, client 102 renders the html on the browser. Once step 214 is 

complete, the resource that was requested at step 202, including the associated "fast" 
cookies has been sent to client 102 from server 104 with the exception of the "slow" 
cookie(s). 

[0027] At step 216, client 1 02 establishes a connection or sends a request for the clear 
gif that is represented by the link. 

At step 218, server 1 04 receives the connection request for the clear gif. 

At step 220, server 1 04 starts a timer. This timer is used to avoid time-out 
problems on the browser and also avoid errors from what appears to be a persistent 
connection between the client and the browser. In one embodiment, the timer is a 
count-down timer and is set to 20 seconds. 

At step 221 , server 1 04 checks to see if the cookie, requested at step 206, is 
present in the send queue. Therefore, it is helpful to understand the cookie 
steps that occur after step 206. 

At step 230, cookie generator 106 receives the request to generate a cookie that 
server 1 04 sent at step 206. 

At step 232, cookie generator 1 06 generates the requested cookie. As an 
example, this could be a GET ACCESS cookie. 

[0033] At step 234, cookie generator 1 06 sends the requested cookie to server 1 04. 

[0034] At step 236, server 1 04 receives the requested cookie and puts the cookie in a 
send queue. 

[0035] 

The time required for cookie generator 106 to complete steps 230 through 234 is 
normally greater than the time required takes for server 1 04 to complete steps 206 
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through 210. For this reason, server 1 04 normally receives the cookie at step 236 
after completing step 210. Although not illustrated, if the requested cookie is received 
at step 236 before server 1 04 completes step 21 0, the requested cookie can be 
included with the html at step 210. However, it is also possible that even though the 
cookie is received before server 104 completes step 210, the requested cookie is not 
included with the html at step 210. 

[0036] After starting the timer at step 22, at step 221 , server 1 04 determines whether the 
requested cookie is present in the send queue. If the cookie is present, then at step 
226, server 1 04 sends the cookie to the client browser as part of the header in the 
clear gif. 

[0037] At step 228, client 1 02 receives the clear gif, including the cookie in the header, 
and the browser "renders" the clear gif. 



[0038] If, at step 221 , server 1 04 determines that the requested cookie is not present in 
the send queue, than at step 222, server 104 determines whether the timer, started at 
y, step 220, has expired. If the timer has not expired, server 104 loops to step 221 and 

continues to monitor or check for the cookie in the send queue. 

m [0039] If at step 222, server 1 04 determines that the timer has expired, then at step 224, 
■?} client 102 is provided instructions, such as through a redirect, to reload the process, 

hi 



and loops to step 216. 

[0040] The techniques that have been described can be implemented in a number of 

different ways. In one embodiment, the link to the clear gif is manually inserted into 
the html during page development. In another embodiment, the link to the clear gif is 
automatically inserted by a plug-in that edits the html output of the application 
server. In another embodiment, a spacer gif is automatically used, resulting in no 
changes to the html. This last embodiment is particularly useful where the web site is 
designed using a "what you see is what you get" ("Wysiwyg") editor. 

[0041] Although illustrative embodiments have been described herein in detail, it should 
be noted and will be appreciated by those skilled in the art that numerous variations 
may be made within the scope of this invention without departing from the principle 
of this invention and without sacrificing its chief advantages. Such variations include: 
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the clear gif can be reloaded not by http redirects but rather by JavaScript that 
switches the image; the cookies can be set by a webserver plug-in or html included in 
every page that checks each time a page is requested to see if the slow cookies have 
been retrieved; or the cookies can be set by a bounce page when the user clicks a link 
requiring the cookies. There are various advantages and disadvantages of these 
variations. 

[0042] Unless otherwise specifically stated, the terms and expressions have been used 

herein as terms of description and not terms of limitation. There is no intention to use 
the terms or expressions to exclude any equivalents of features shown and described 
or portions thereof and this invention should be defined in accordance with the claims 
that follow. 
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